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Scope 


The  scope  of  this  document  is  the  procedures  and  requirements  for  developing  an  Initial 
Manufacturing  Exchange  Specification. 

Intended  Audience 

The  initial  audience  for  this  document  includes  those  System  Integration  for  Manufacturing 
Applications  (SIMA)  projects  performing  applied  research  and  development  of  solutions 
satisfying  manufacturing  systems  integration  problems. 

Document  Status 

This  document  is  in  its  first  phase  as  an  initial  release  document.  As  users  of  this  document  gain 
more  experience  in  applying  the  concepts  and  procedures  to  IMES  development,  the  document 
wiU  continue  to  be  improved  and  republished  with  these  improvements. 

Introduction 

The  goal  of  the  U.S.  government’s  High  Performance  Computing  and  Communication  (HPCC) 
Program  is  to  accelerate  the  development  of  future  generations  of  high  performance  computers 
and  networks  and  the  use  of  these  resources  in  the  government  and  throughout  the  U.S.  economy. 
The  HPCC  Program  was  formally  established  by  the  High  Performance  Computing  Act  of  1991 
(Public  Law  102-194).  The  four  original  components  of  the  HPCC  Program  were  augmented  in 
FY94  with  a new  component  known  as  Information  Infrastructure  Technology  and  Applications 
(IITA).  The  HTA  component  supports  research  and  development  efforts  that  will  enable 
integration  of  critical  information  systems  and  demonstrate  feasible  solutions  to  problems  of 
national  importance.  Twenty-first  century  manufacturing,  i.e.,  advanced  manufacturing  processes 
and  products,  is  one  of  the  challenges  to  be  addressed  by  IITA  activities.  Starting  in  FY97,  the 
components  of  the  HPCC  Program  are  broadened  and  refocused  into  Program  Component  Areas 
(PCAs).  These  PCAs  build  on  the  foundations  established  m the  previously  identified  component 
domains  and  continue  to  address  the  HPCC  challenge  problems.  The  PCAs  are  known  as  High 
End  Computing  and  Computation,  Large-Scale  Networking,  High  Confidence  Systems,  Human- 
Centered  Systems,  and  Human  Resources,  Education,  and  Training.  The  Human  Centered 
Systems  (HuCS)  PCA  - which  evolved  from  the  ETA  component  - performs  research  and 
development  making  the  products  of  computing  systems  and  communication  networks  more 
easily  accessible  and  useable  to  a wide  range  of  user  communities.  Information  interface  issues 
are  central  to  such  research  and  development  efforts. 

NIST’s  SIMA  Program  is  the  agency’s  coordinating  focus  for  its  HPCC  activities  addressing  the 
information  interface  needs  of  ie  U.S.  manufacturing  community.  Specifically,  the  SIMA 
Program  works  with  U.S.  industry  to: 

• Develop  information  exchange  and  interface  protocol  standard  solutions  for  manufacturing 
integration  problems, 

• Establish  test  mechanisms  for  validating  solutions  and  implementations,  and 

• Transfer  information  technology  solutions  to  manufacturing  enterprises. 
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These  efforts  will  allow  manufacturing  industries  to  make  use  of  the  National  Information 
Infrastructure  (Nil)  as  a mechanism  for  communicating  product  and  process  data  among  various 
manufacturing  activities  such  as  product/process  design,  analysis,  planning,  scheduling, 
production,  and  quality  control.  Manufacturing  applications  require  standard  protocols  for  data 
exchange  (information  interfaces)  to  communicate  with  each  otiier  via  Nil  technologies.  The 
development  of  information  interfaces  between  the  communications  infrastructure  and 
manufacturing  applications,  between  different  manufacturing  applications,  and  between  these 
applications  and  their  users  will  improve  integration  and  thereby  usability  of  these  systems. 

There  are  three  major  thrusts  for  SIMA: 

• developing  and  demonstrating  specifications  for  product  and  process  data  exchange  between 
hfe-cycle  applications  used  in  manufacturing  industries  (mechanical  parts,  electronic 
components,  and  process  plants), 

• developing  tools  and  supporting  conformance,  interoperability,  and  performance  testing 
programs  for  data  exchange  standards,  and 

• developing  advanced  computing  and  communications  capabihties  used  for  development  and 
dissemination  of  integration  solutions,  and  providing  on-line  access  of  standard  reference 
data  and  manufacturing  information  about  on-going  R&D  activities. 

The  primary  output  of  the  SIMA  Program  will  be  suites  of  specifications  that  meet  the 
interoperability  needs  for  the  defined  manufacturing  life-cycle  applications.  Some  of  these 
specifications  will  be  developed  within  SIMA,  while  others  will  be  adopted  from  existing 
standards  activities  underway  elsewhere.  Key  to  the  success  of  the  suites  being  accepted  by 
industry  is  the  second  aspect:  demonstrating  that  the  specifications  are  solutions  to  real 
manufacturing  integration  problems. 

To  ensure  acceptance,  developing  these  suites  of  specifications  will  involve  collaborations  with  a 
variety  of  organizations.  These  collaborations  will  take  on  a variety  of  working  relationships  that 
will  be  defined  through  cooperative  agreements.  Examples  of  these  collaborations  include: 

• Identifying  standards  development  organizations  (SDOs)  so  that  an  established  path  from  a 
specification  to  a standard  is  supported; 

• Leveraging  national  programs  such  as  the  National  Industrial  Information  Infrastructure 
Protocols  (NULP),  Technology  for  Enabling  Agile  Manufacturing  (TEAM),  Manufacturing 
Automation  and  Design  Engineering/Rapid  Design  Exploration  and  Optimization 
(MADE/RADEO),  and  PDES  Inc.  STEP  Pilots  so  that  SIMA  project  managers  can  apply 
their  expertise  in  developing  specifications  while  other  programs  concentrate  on  improving 
the  capabilities  of  the  manufacturing  life-cycle  applications; 

• Pursuing  collaborations  with  software  vendors  to  demonstrate  how  the  specifications  can  be 
used  in  actual  software  products; 

• Establishing  collaborations  with  end-users  of  software  products  to  validate  solutions  for 
specific  integration  problems; 

• I^irsuing  academic  collaborators  to  help  advance  the  technology  as  needed;  and 
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Working  closely  with  other  government  agencies  such  as  Departments  of  Energy  and 
Defense,  National  Science  Foundation,  and  National  Aeronautical  & Space  Administration  to 
leverage  each  other’s  results. 


In  addition,  a set  of  companion  documents  to  the  IMES  will  be  defined  that  will  allow  the  results 
of  the  IMES  process  deliverables  to  be  published  at  key  phases  of  its  life-cycle.  Both  the  IMES 
and  its  companion  documents  will  have  a rigorous  review  process  to  ensure  the  results  are  of  the 
highest  quality  and  meet  the  original  requirements  identified  by  industry. 

The  IMES  will  fill  an  important  void  in  the  manufacturing  systems  integration  process  as  it  exists 
today.  It  is  clear  that  companies  need  to  have  interoperable  manufacturing  systems  to  function  in 
an  agile  environment.  To  accomplish  such  interoperability  requires  the  necessary  exchange 
standards.  However,  there  is  a clear  recognition  in  the  standards  community  that  the  process 
leading  to  standards  is  very  slow.  The  IMES  provides  a mechanism  to  develop  interim  fast-track 
specifications  that  can  be  tested  in  pilot  projects  before,  or  in  parallel  to,  submission  to  a formal 
standards  development  process.  As  an  organization,  NIST  is  positioned  as  the  appropriate 
organization  to  develop  IMESs  because  it  is  viewed  as  an  objective  third-party  in  the  area  of 
specification  development.  Also,  and  most  importantly,  NIST  is  committed  to  ultimately  ensure 
the  IMES  enters  the  formal  standards  process  at  the  appropriate  time. 


IMESs  provide  the  means  to  improve  the  SIMA  Program's  ability  to  meet  the  needs  of  the  U.S. 
industry  in  the  area  of  standards  and  testing  methods  by  providing  a structured  approach  to  the 
SIMA  Program's  activities  in  this  arena.  This  methodology  is  not  completely  new,  but  rather  is  a 
mixture  of  the  best  techniques  presently  available  to  SIMA  staff.  It  is  also  influenced  by  the 
more  efficient  processes  used  by  stand^ds  development  organizations  and  industry  programs  that 
support  these  efforts. 

Current  IMESs  under  development  within  the  SIMA  Program  include: 

• Assembly  constraints  representations  for  virtual  assembly, 

• Product  data  management  application  interface  protocol, 

• Manufacturing  plant  layout  representations, 

• Manufacturing  resource  data  representations,  and 

• Shop  floor  status  representations. 

Although  many  types  of  documentation  and  supporting  efforts  are  developed  during  the  phases  of 
IMES  development,  the  ultimate  product  is  an  exchange  specification.  Throughout  this 
document  you  will  see  "specification"  and  "IMES"  used  interchangeably. 


The  remainder  of  this  document's  content  is  structured  as  follows: 


Chapter  1:  provides  a general  definition  for  an  IMES,  describes  desired  characteristics  of  an 

IMES,  and  gives  examples  of  existing  efforts  or  documents  that  could  be  considered 
portions  of  an  IMES. 


Chapter  2:  defines  the  methodology  for  developing  an  IMES,  outlines  the  various  phases 

required  for  IMES  development,  and  identifies  appropriate  deliverables  for  each 
IMES  development  phase. 

Chapter  3:  defines  the  approval  process,  metrics,  and  other  considerations  used  to  determine 
completion  of  IMES  deliverables  and  each  IMES  development  phase. 

Chapter  4:  provides  some  initial  metrics  to  assess  the  success  of  completed  IMESs,  and  a brief 
conclusion  for  this  document. 
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Several  appendices  follow  the  main  body  of  the  document,  covering:  a glossary  of  references, 
acronyms  and  terms,  bibliography  of  documents  for  IMES  development,  examples  of  IMES 
deliverables,  and  a description  of  roles  and  responsibilities  of  those  involved  in  the  IMES  process 
for  this  document. 
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Chapter  1:  What  is  an  Initial  Manufacturing  Exchange  Specification  (IMES)? 


An  IMES  is  a proposed  solution  aimed  at  improving  interoperability  among  independently 
developed  manufacturing  software  systems.  In  general,  it  is  the  specification  of  an  interface 
between  software  systems  to  be  used  in  supporting  a particular  manufacturing  activity  or 
manufacturing  scenario.  An  IMES  is  developed  through  an  industry  review  and  consensus 
process  and  is  accepted  by  the  manufacturing  community  as  an  authoritative  specification. 

There  are  three  types  of  IMESs  that  may  be  developed: 

• an  interface  specification  between  a human  being  and  a software  application; 

• an  interface  specification  between  two  or  more  software  applications;  or 

• a reference  information  repository  specification. 


These  are  graphically  depicted  in  Figure  1. 


Human-to-Software  Interface 


Applica tion-to-A pplica tion  Interface 


nCUREl:  THREE  TYPES  OF  IMES 
A complete  IMES: 

• specifies  the  scope  and  domain  of  its  applicability,  with  a supporting  manufacturing  scenario; 

• specifies  the  interface  or  information  repository; 

• identifies  its  own  status,  as  of  publication,  in  a formal  standardization  organization; 

• states  if  any  implementations  are  available;  and 

• references  the  source  documents  from  which  it  is  derived,  or  on  which  it  depends. 

The  following  paragraphs  provide  more  detail  on  these  IMES  characteristics. 
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1.1  Scope,  Domain,  and  Manufacturing  Scenario 

An  IMES  must  specify  the  scope  and  domain(s)  of  the  manufacturing  software  activities  it  is 
intended  to  serve.  The  scope  specifies  the  manufacturing  activities  it  is  designed  to  serve,  and 
the  specific  stages  in  the  product  life  cycle  supported.  The  domain  identifies  the  kind(s)  of 
products  being  manufactured.  An  activity  to  model/define  the  actual  processes  used  in  a 
particular  industry  may  be  a necessary  forerunner  to  developing  any  IMES  in  that  area.  Where 
such  a model  has  been  developed,  the  specification  should  reference  the  relevant  activities  and 
flows  described  by  that  model,  and  possibly  expand  on  it. 

To  support  the  scope  and  domain  specifications,  the  IMES  shall  address  a particular  "example 
scenario,"  identifying  an  acmal  interface/information  requirement  derived  from  a real  industrial 
problem.  The  proof  of  the  value  of  the  EMES  to  industry  will  be  the  ability  to  build  a prototype 
to  the  IMES,  using  the  software  applications  actually  used  by  the  industrii  practitioners,  and 
solving  the  cited  problem.  Figure  2 shows  the  data  planning  model  for  the  application  protocol 
ISO  10303-202,  Application  protocol:  Associative  draughting’,  in  essence,  a high  level  depiction 
of  ISO  10303-202's  scope  and  domain  to  meet  the  particular  industrial  need  [10303-202]. 
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FIGURE  2:  SAMPLE  fflGH  LEVEL  DEPICTION  OF  SCOPE  AND  DOMAIN 
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1.2  Specifications 

An  IMES  is  a proposed  standard  solution  for  a given  aspect  of  manufacturing  system  integration. 
The  aspect  itself  is  exemplified  by  the  industrial  scenario  involving  integration  of  two  or  more 
manufacturing  software  systems.  Developed  from  an  industry  consensus  vie'wpoint,  the  IMES  is 
accepted  by  the  manufacturing  community  as  an  authoritative  information  specification  for  the 
given  scenario.  An  IMES  involves  several  components  which  define  the  integration  aspect, 
specifies  a definitive  solution  to  the  integration  problem,  and  demonstrates  the  validity  of  the 
proposed  solution. 

An  IMES  contains  a clear  description  of  WHAT  information  the  interface  or  repository  MUST 
convey,  and  possibly  HOW  it  is  conveyed.  The  notion  "how"  may  involve  several  levels  of 
definition,  typically  by  referring  to  other  specifications.  Where  possible,  an  IMES  should  use, 
incorporate,  or  refer  to  existing  formal  or  de  facto  nonproprietary  standards. 

All  IMESs  specify  the  information  which  is  to  be  exchanged.  The  content  is  usually  specified  by 
an  information  model  of  all  the  objects  and  related  information  attributes  which  are  covered  by 
the  specification.  For  example.  Figure  3,  depicts  the  information  requirements  in  EXPRESS,  and 
the  associated  graphical  representation  (EXPRESS-G)  for  personnel  data. 


Example  of  EXPRESS  and  EXPRESS-G  Representation: 

ENTITY  company; 
address : STRING; 

composed_of : SET[1:?]  OF  department; 

END.ENTITY; 


ENTITY  department; 
location ; STRING; 
staff : SET[1:?]  OF  employee; 
END.ENTITY; 


ENTITY  employee; 

SUPERTYPE  OF  (ONEOF(salaried,  hourly)): 
lasmame  : STRING; 
firstname : STRING; 
ssn  : INTEGER; 

END.ENTITY; 

ENTITY  salaried; 

SUBTYPE  OF  (employee); 

END.ENTnT; 


ENTITY  hourly; 

SUBTYPE  OF  (employee); 
rate : REAL; 
END.ENTITY; 


FIGURE  3:  SAMPLE  EXPRESS  AND  EXPRESS-G  REPRESENTATIONS 
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When  the  exchange  of  information  uses  a repository,  the  IMES  must  define  an  information 
model  for  the  content  of  the  exchange.  The  model  may  also  define  the  protocol  for 
communication  with  the  repository  system.  When  the  exchange  of  information  is  directly 
between  two  software  applications,  the  IMES  must  define  the  protocol  for  the  exchange  of 
information  between  the  two  apphcations. 

Where  the  software  packages,  or  parts  of  them,  are  meant  to  be  incorporated  in  a single 
executable  program,  the  protocol  specification  takes  the  form  of  an  Application  Programming 
Interface  (API).  A standard  API  specifies  a mapping  between  a programming  language  and  the 
features  of  a particular  service,  and  thereby  provides  access  to  that  service  from  apphcations 
written  in  a particular  programming  language.  Such  a mapping  is  said  to  create  a binding 
between  the  service  and  the  programming  language.  A standard  API  may  be  part  of  the  standard 
that  specifies  the  associated  programming  language,  may  be  part  of  the  standard  that  specifies  the 
associated  service,  or  may  be  a separate  standard  that  refers  to  other  standards  that  define  the 
associated  programming  language  and  service  [JTCl].  An  API  defines  the  subroutine 
entry-points  to  be  called  by  the  one  apphcation  and  provided  by  the  other,  or  equivalently,  the 
objects  provided  by  the  one  and  the  methods/messages  on  those  objects  which  can  be  invoked  by 
the  other.  (The  latter  is  sometimes  termed  a class  library  specification.)  For  information  objects 
exchanged  via  the  call  or  invocation,  the  IMES  must  specify  the  parameters.  There  are  two  types 
of  parameters:  those  which  have  specified  data  types  and  possibly  specific  values,  and  those 
which  are  the  identifiers  of  "opaque"  objects  whose  structure  is  known  only  to  one  or  the  other 
side  of  the  exchange.  In  addition,  the  IMES  must  specify  additional  shared  information  objects, 
if  any,  and  rules  for  the  sequencing  of  calls/invocations. 

A practical  example  of  API  development  is  the  TEAM  API  specification.  TEAM’S  API  applies 
to  closed  loop  processing  - including  module  interface  programming;  command,  control  and 
communication;  infrastructure  and  system  services;  and  the  scaling  of  functionality  based  on 
selected  equipment  and  desired  application.  The  key  objective  of  defining  a TEAM  API 
specification  is  to  enable  the  design  and  implementation  of  an  open,  modular  control  architecture 
[TEAM]. 

Where  the  software  packages  are  expected  to  be  stand-alone  systems  that  communicate  with  one 
another,  the  protocol  takes  the  form  of  a communications  protocol,  defining  messages,  requests, 
and  responses;  and  the  specific  form  of  the  message  on  the  network.  In  many  cases,  such  a 
specification  will  also  identify  the  standards  to  be  used  for  conveying  the  messages,  such  as  a 
Common  Object  Request  Broker  Architecture  (CORBA)  specification  [OMG]. 

Some  direct  communication  IMESs  may  involve  both  communication  protocols  and  APIs.  Some 
EMESs  may  specify  both  direct  communication  and  related  shared  databases  or  repositories. 

Some  IMESs  may  mandate  the  use  of  other  standards  which  allow  the  derivation  of  the  complete 
interchange  specification.  For  example,  an  IMES  may  specify  a service  API  using  CORBA 
Interface  Description  Language  (IDL)  and  require  the  use  of  a CORBA  Object  Request  Broker 
(ORB)  implementation  to  provide  the  actual  communications  protocol  [OMG].  Similarly,  an 
IMES  may  contain  an  EXPRESS  [10303-1 1]  model  and  allow  exchange  by  file  using  STEP  clear 
text  encoding  [10303-21]  to  define  the  exchange  representation,  or  exchange  by  a shared 
database  using  the  STEP  Standard  data  access  interface  (SDAl)  specification  [10303-22]  to 
define  the  API. 

1.3  Formal  Status  of  the  IMES  Within  Standards  Development  Organizations 

An  IMES  may  reference  an  existing  specification  and  recommend  its  use  for  aU  or  part  of  a 
particular  integration  requirement.  If  the  IMES  is  or  becomes  a formal  standard,  via  ISO,  ANSI, 
OMG,  or  ISA,  then  the  specification  shall  identify  the  formal  standard  development  organization. 
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An  IMES  may  adapt  or  adopt  an  existing  specification  that  has  no  formal  standard  status,  but  is 
the  subject  of  agreements  by  consortia  or  national  projects  or  initiatives.  In  such  a case,  the 
IMES  project  shall  ensure  that  there  is  a published  specification  and  shall  identify  that 
publication. 

If  the  IMES  has  been  proposed  as  a formal  standard  to  be  considered  by  a standards  development 
organization,  or  has  achieved  some  status  on  the  way  to  standardization,  the  standardization 
body  and  status  shall  be  referenced  in  the  EMES. 

Finally,  a SIMA  project  may  determine  that  there  is  no  available  specification  and  initiate  or 
participate  in  an  effort  to  develop  an  IMES  jointly  with  industrial  consortia  or  standards  bodies. 
An  IMES  which  is  purely  a draft  specification  of  this  type  shall  indicate  this  as  its  formal  status. 
If  the  draft  specification  is  under  consideration  by  a standards  development  organization  or  has 
achieved  some  status  on  the  way  to  standardization,  the  standardization  body  and  status  shall  be 
identified. 

1.4  IMES  Implementations  Available 

Since  an  IMES  may  adopt  an  existing  specification,  there  may  already  be  examples  of 
implementations  of  that  IMES.  These  should  be  highlighted  within  the  IMES  so  that  current  and 
future  users  of  the  specification  will  know  there  is  supplier  support  and  commercial  off-the-shelf 
solutions  available.  Where  public  domain  implementations  exist,  the  IMES  should  identify  the 
procedures  one  would  employ  to  acquire  such  implementations.  The  IMES  must  state  that 
mention  of  any  implementations  does  not  suggest  endorsement  of  the  implementation  by  NIST  or 
the  United  States  government. 

1.5  Resource  Documents  for  an  IMES 

The  IMES  shall  reference  any  document  which  was  used  as  a source  for  any  part  of  its  contents. 

A reference  document  could  come  from  any  number  of  sources.  It  could  be  a white  paper  of 
concepts,  published  research  paper,  post-graduate  thesis,  industrial  workshop  output,  or  a 
preliniinary  requirement  identified  by  a standards  development  organization.  The  common 
element  across  all  of  these  types  of  reference  documents  is  that  the  idea,  once  written,  lay 
potentially  dormant  for  want  of  an  organization  such  as  NIST  to  harness  the  resources  and  spark 
the  concept  into  a practical,  implementable  specification  — an  IMES. 

The  IMES  shall  identify  any  document  on  which  its  utihty  depends.  For  example,  an  IMES 
phrased  as  an  EXPRESS  information  model  for  a database  to  be  accessed  by  SDAI  shall  identify 
the  relevant  STEP  parts.  Similarly,  an  IMES  phrased  in  IDL  and  depending  on  a CORBA 
implementation  shall  identify  the  relevant  OMG  standards.  All  such  reference  documents  should 
be  publicly  available  and  the  source  specified. 

1.6  Examples  of  IMESs 

IMESs  may  be  developed  as  any  one  of  the  three  types  described  above,  or  a combination  of 
these  types,  such  as  an  application  protocol  for  STEP.  In  developing  the  IMES,  the  expectation 
is  that  the  developers  will  build  upon  methodologies  and  document  formats  that  are  already  in 
existence  and  can  be  merged  into  a structure  that  will  be  appropriate  for  the  SIMA  efforts.  The 
following  are  some  good  examples  that  can  serve  as  a basis  for  obtaining  the  desired  IMES 
format. 
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The  requirements  specification  Modeling  of  Manufacturing  Resource  Information  [JUR95],  from 
the  NIST  Rapid  Response  Manufacturing  (RRM)  Intramural  Project,  is  an  example  of  a proposed 
requirements  specification  which  defines  the  information  model  for  a reference  information 
repository.  The  models  are  formulated  in  EXPRESS  [ISO  10303-1 1],  which  allows  the  schema 
to  be  considered  for  a repository  that  supports  SDAI  [10303-22]  as  the  application  program 
interface.  Thus  the  specification  defines  the  information  model  and  the  repository  schema,  and 
specifies  SDAI  as  the  repository  access  protocol. 

The  MSI  Control  Entity  Interface  Specification  [WAL93]  is  an  example  of  a possible  IMES  for 
controller  and  scheduler  interfaces  using  direct  communications  protocols.  The  specification 
defines  the  scenario  and  assumptions  about  the  communicating  software  applications  and 
specifies  the  messages  to  be  exchanged  and  the  rules  for  the  exchange.  The  messages  are 
formulated  in  Asynchronous  Syntax  Notation  (ASN.l)  [8824]  and  are  to  be  encoded  by  the  Basic 
Encoding  Rules  [8825]. 

The  STEP  Application  protocol:  Configuration  controlled  design  [10303-203]  contains  several 
conformance  classes.  Each  class  is,  in  effect,  a separate  candidate  for  an  IMES  to  meet  a 
particular  industry  requirement.  In  particular,  conformance  class  6,  boundary  representation  of 
part  solid  geometry,  specifies  the  information  model  for  the  exchange  of  part  model  geometry 
data  between  a CAD  system  and  some  type  of  analysis  system  or  manufacturing  engineering 
system.  This  model  is  formulated  in  EXPRESS  and  the  IMES  might  specify  encoding  of  an 
exchange  file  using  STEP  clear  text  encoding  [10303-21],  which  is  the  practice  currently 
supported  by  CAD  systems.  Further,  conformance  class  1,  configuration  management  services 
specifies  the  information  model  for  the  information  managed  within  product  data  management 
systems.  Product  data  management  systems  typically  act  as  a reference  information  repository 
among  engineering  systems  to  support  part  and  product  version  and  approval  management. 
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Chapter  2:  IMES  Development  Methodology  for  SIMA  Projects 

2.1  Chapter  Overview 


This  chapter  defines  the  methodology  for  developing  an  IMES.  It  outlines  the  various  phases 
required  for  IMES  development  and  provides  sample  deliverables  for  each  project  phase.  The 
formats  for  the  deliverables  are  given  in  Appendix  D.  A plan  for  developing  an  IMES  should 
describe  project  activities  as  outlined  below  to  completely  define,  justify,  v^date,  demonstrate, 
and  publicize  the  specific  manufacturing  scenario  and  proposed  solution. 

2.2  Phases  of  IMES  Development 

Each  IMES  project  shall  include  the  following  project  phases  as  described  below.  Each  phase  is  a 
required  element  of  the  project.  These  phases  can  be  considered  the  main  task  headings  for  a 
generic  project  plan.  Each  IMES  project  should  further  define  the  specific  tasks  under  each 
heading  to  apply  this  methodology  to  the  proposed  manufacturing  scenario  or  industry  need. 
Additionally,  each  IMES  project  should  identify  the  specific  deliverables  planned  for  each  IMES 
development  phase.  Each  project  must  include,  at  a minimum,  the  primary  deliverable(s)  listed 
below  for  each  development  phase.  Possible  supporting  deliverables  are  also  Listed  below  for 
each  phase.  SIMA  projects  should  identify  any  supporting  deliverables  proposed  for  inclusion  in 
the  project.  The  following  Table  1 summarizes  both  the  primary  and  supporting  deliverables  for 
each  phase.  The  diagram  in  Figure  4 shows  how  the  IMES  phases  interact  with  each  other. 


DELIVERABLES  FOR  EACH  IMES  PHASE 

PHASE 

PRIMARY 

DELIVERABLE(S) 

SUPPORTING 

DELIVERABLE(S) 

Phase  1: 

Identify/define  industry  need 

• problem  statement 

• manufacturing  scenario 

• project  plan 

• industry  needs  survey 

• workshop  proceedings 

• CRADAs 

• MOUs 

• industry  support  letters 

Phase  2: 

Analyze  requirements 

• requirements  specification 
for  a proposed  solution 

• industry  data 

• literature  review 

• standards  review 

• application  software  review 

• state-of-the-art  assessments 

• workshop  proceedings 

• identification  of 
potential/appropriate  standards 
bodies 

Phase  3: 

Design/develop 

• initial  strawman  IMES 

• information  model(s) 

• interface  protocol(s) 

• process  model(s) 

Phase  4: 

Validate 

• test  results 

• prototype  implementation, 

• Test  environment 

• Test  suites 
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1 DELIVERABLES  FOR  EACH  IMES  PHASE 

PHASE 

PRIMARY 

DELIVERABLE(S) 

SUPPORTING 

DELIVERABLE(S) 

Phase  5: 

Build  Consensus 

• Reviewed/harmonized  IMES 

• workshop  proceedings 

• industry  review 

• standards  development 
organization  review 

• industry  user  group  interest/actions 

Phase  6 

Transfer  technology 

• IMES  final  report 

• system  demonstrations 

• conference  presentation 

• journal  articles 

• WWW  homepages 

• vendor  implementations 

• end-user  implementations 

• commercialization  plan 

• toolkit  software  release 

Phase  7 

Initiate  standardization 

• standards  development 
organization  new  work  item 

• strawman  proposal 
recognized  as  committee 
draft  (CD)  status 

• strawman  proposal  for 
standardization 

• standards  development 
organization  new  working  group 

• amendment  or  technical 
corrigendum  to  existing  standard 

• implementors’  agreement/profile 
project  plan  and  schedule  for 
developing  IMES  through 
standards  development 
organization 

TABLE  1:  DELIVERABLES  FOR  EACH  IMES  PHASE 
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FIGURE  4:  IMES  PHASES 


Phase  1 - Identify/Define  Industry  Need 

The  initial  activity  of  IMES  development  is  identifying  and  documenting  an  industry  need, 
manufacturing  scenario,  or  problem  statement  to  define  the  scope  and  manufacturing  domain  of 
the  proposed  project.  This  need  could  be  identified  in  several  ways.  Typically,  however, 
industrial  collaborators  should  be  involved  in  defining  this  need.  This  activity  involves  the 
project  planning  required  to  initiate  an  IMES  development  effort  to  address  the  stated 
manufacturing  scenario.  This  phase  shall  also  define  the  interface  and  relationships  between  the 
proposed  project  and  the  SIMA  Reference  Architecture,  other  related  projects,  and  existing 
standards  activities. 

Phase  2 - Analyze  Requirements 

This  IMES  development  phase  consists  of  analyzing  the  current  situation  within  the 
manufacturing  scenario  to  understand  current  capabilities,  prior  attempts  at  a solution,  and 
specific  needs  that  must  be  accommodated  in  the  proposed  IMES  solution.  A requirements 
specification  is  the  primary  desired  output  from  this  project  phase.  Such  a specification  wiU 
enable  widespread  industry  review  of  the  detailed  requirements  which  a solution  must  satisfy  in  a 
form  that  is  understandable  by  the  majority  of  the  target  manufacturing  community. 
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Phase  3 - Design/Develop 

This  IMES  development  phase  consists  of  the  actual  design,  development,  and  documentation  of 
the  proposed  IMES  technical  solution  which  satisfies  the  requirements  specified  in  the  previous 
phase.  The  solution  may  consist  of  a combination  of  deliverable  types,  including  information 
model(s),  interface  protocol(s),  or  process  model(s),  as  required  by  the  project.  The  primary 
output  of  this  phase  is  the  initial  version  of  the  strawman  proposal  for  external  review. 

The  content  of  IMES  deliverables  will  vary  depending  upon  the  type  of  IMES.  The  following 
guidance  is  provided.  If  the  SIMA  project  is  developing: 

• an  interface  between  two  applications,  an  IMES  shall  describe  the  information  model  along 
with  the  interface  protocol  used  by  these  applications. 

• a series  of  interfaces  between  several  pairs  of  applications  which  all  need  to  work  together, 
then  either  several  information  models  are  needed  or  a single  model  which  identifies  the 
partitions  of  information  needed  by  each  application  must  be  provided.  In  addition,  a process 
model  shaQ  be  provided  which  describes  how  aU  of  these  applications  work  together  along 
with  the  communication  or  exchange  mechanism  used  by  these  applications. 

• an  interface  between  a human  and  a software  package,  an  IMES  shall  describe  the 
information  model  and  the  way  in  which  that  data  is  organized  and  presented  to  the  human. 

• a shared  reference  information  repository,  then  an  IMES  shaU  include  a information  model 
for  that  repository  and  a description  of  the  sharable  data  collections  among  applications. 
Depending  on  the  needs  of  an  application,  the  minimum  meaningful  data  collection  to  be 
accessed  might  be  a cohesive  set  of  highly  interrelated  information  (e.g.,  a design),  or  a 
simple  occurrence  (e.g.,  a result  of  an  operation).  In  addition,  a process  model  should  be  used 
to  describe  which  applications  create  and  modify  access  units  in  the  repository.  The 
mechanism  to  be  used  for  communicating  with  the  repository  shall  also  be  specified. 

Phase  4 --  Validate 

A validation  phase  is  required  to  ensure  the  completeness,  validity,  and  usability  of  the  proposed 
IMES  solution.  Validation  activities  may  take  several  forms,  including:  prototype 
implementations,  detailed  walk-throughs  with  domain  experts,  or  a comparison  with  known 
references.  A proposed  solution  with  demonstrated  prototype  implementations  and  validation  test 
results  makes  a much  stronger  case  for  standardization.  W^en  viidation  activities  include 
industry  review  or  prototype  implementations  developed  by  external  organizations,  this  project 
phase  may  have  some  overlap  with  other  IMES  development  phases  (e.g.,  consensus-building, 
technology  transfer).  The  documented  test  results  (obviously  based  upon  the  prototype 
implementation,  test  environment,  test  suites,  or  other  validation  tools)  are  considered  the 
primary  output  of  this  phase. 

Phase  5 - Build  Consensus 

By  definition,  an  IMES  is  developed  firom  an  industry  consensus  viewpoint.  Whereas  most  IMES 
development  phases  require  some  collaboration  or  interaction  with  mdustrial  counterparts,  this 
phase  of  IMES  development  requires  interaction  with  a large  segment  of  the  target  manufacturing 
community.  This  interaction  can  be  accomplished  through  technical  workshops,  user  group 
meetings,  correspondence,  or  site  visits.  IMES  development  projects  should  endeavor  to  obtain 
and  accommodate  as  much  input  and  feedback  from  industry  as  possible  in  the  proposed  project 
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solution.  It  is  recognized  that  true  consensus  may  never  be  reached.  This  project  phase  is  deemed 
necessary,  however,  for  positioning  and  delivering  a quality  proposed  strawman  for 
standardization  to  an  appropriate  standards  development  organization.  This  phase  is 
differentiated  from  the  actual  standardization  process  to  allow  and  encourage  other 
consensus-building  activities  without  the  potential  constraints  and  procedures  required  by 
standards  organizations.  The  primary  deliverable  of  this  phase  is  an  updated  Strawman  IMES 
resulting  from  the  consensus-budding  activities.  In  some  cases,  significant  comments  and 
suggestions  may  indicate  the  need  for  the  project  to  iterate  back  to  the  IMES  Design/develop 
Phase  3. 

Phase  6 - Transfer  Technology 

One  of  the  primary  missions  of  NIST  is  to  provide  technology  transfer  of  NIST  research  results 
to  industry.  The  SIMA  Program  supports  this  mission.  IMES  development  efforts  will  include 
aspects  of  technology  transfer  to  publicize,  market,  and  transition  project  activities  and  results  to 
industry  or  standards  development  organizations.  Technology  transfer  should  be  an  ongoing 
project  activity.  Various  me^ods  of  technology  transfer  can  be  employed  at  the  various  stages  of 
the  IMES  development  effort  to  supply  industiy  collaborators  and  the  manufacturing  community 
with  current  information.  The  primary  deliverables  for  this  phase  consist  of  a final  report  and 
system  demonstrations.  The  final  report  should  document  the  activities  of  the  IMES  development 
(what,  why,  and  how),  specific  results  of  validation  and  consensus-building  efforts,  and  lessons 
learned  from  the  experience  of  developing  the  IMES.  The  final  report  should  also  include  an 
implementor’s  guide  to  instruct  vendors  how  to  implement  the  IMES  and  a user's  guide  to 
instruct  manufacturing  users  how  to  use  the  IMES  to  meet  their  requirements. 

Phase  7 - Initiate  Standardization 

Since  an  IMES  is  a proposed  standard  solution  to  a manufacturing  scenario,  IMES  development 
efforts  must  include  interaction  with  appropriate  standards  development  organizations  to  initiate 
the  formal  standardization  process.  These  activities  may  include  attending  standards  meetings, 
participating  on  relevant  standards  committees,  or  writing  project  correspondence  to  standards 
development  organization  conveners.  The  objective  of  this  phase  is  to  initiate  the  proposed 
standards  work  (either  as  a new  work  item  or  modifications  to  existing  standards/work  items)  to 
a point  where  it  will  be  self-sustaining  within  the  standards  development  organization.  Examples 
of  this  stage  include:  evidence  that  interest  has  been  generated  witfan  a standards  committee,  a 
new  work  item  is  accepted,  committee  members  are  identified,  general  agreement  that 
modifications  to  existing  work  are  necessary,  or  a strawman  proposal  is  registered  as  a committee 
draft  (CD).  It  is  not  expected  that  SIMA  project  resources  will  carry  through  for  the  full  duration 
of  standardization  once  the  standards  work  has  been  sufficiently  initiated  and  has  become  self- 
sustaining.  Projects  should  consider  that  a strawman  proposal  for  standardization  must  be 
developed  with  sufficient  consensus  and  validation  prior  to  submitting  the  IMES  for 
standardization. 
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2.3  Project  Scheduling  Considerations 

IMES  development  phases  typically  build  upon  each  other,  but  are  not  meant  to  imply  total 
sequential  processing.  In  many  cases  project  phases  must  be  performed  in  parallel  to  plan  and 
position  project  activities  effectively.  Results  of  some  phases  will  also  indicate  the  need  to  iterate 
back  to  refine  and  update  a prior  phase.  For  planning  purposes,  SEMA  projects  should  expect  to 
complete  Phases  1 through  7 within  a three-year  period.  It  is  expected  that  sufficient  results  will 
be  obtained  to  initiate  standards  work  by  the  end  of  the  third  year.  It  is  recognized  that  actual 
standardization  of  the  proposed  solution  could  potentially  require  several  years  beyond  this  three 
year  IMES  development.  These  standardization  activities  are  not  addressed  by  the  IMES 
development  process. 

2.4  IMES  Process  Example 

As  mentioned  earlier  in  this  document  one  EMES  currently  in  development  is  that  for 
manufacturing  resource  data  representations  [JUR95].  That  effort  has  been  performed  in 
conjunction  with  the  National  Center  for  Manufacturing  Science’s  (NCMS)  Rapid  Response 
Manufacturing  (RRM)  consortium  over  the  past  four  years.  Figure  5,  depicts  how  the  activities 
and  results  performed  in  that  effort  map  into  the  IMES  phases.  For  phase  1 needs  surveys  and 
state-of-the-art  assessments  led  to  the  definition  of  an  industry  need  and  a plan  for  addressing 
that  need.  In  phase  2 a detailed  specification  of  requirements  was  published.  In  phase  3 an 
information  model  satisfying  the  requirements  specification  was  produced.  In  phase  4 a test 
environment  for  prototype  implementations  was  developed.  In  phase  5 industry  reviews  of  the 
specifications  were  performed.  In  phase  7 presentations  of  the  work  to  relevant  standards  bodies 
was  performed  and  a “home”  for  the  work  was  identified.  It  is  noteworthy  that  technology 
transfer  (phase  6)  is  performed  throughout  the  process  and  not  just  as  a single,  sequential  aspect 
of  the  effort. 
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RRM  Intramural  Project 

Correspondence  of  MR  Data  Efforts  to  EVDES  Methodology 


Phase  1 


NCMSRRM&MSID 
Needs  Survey 
SOTA  Assessments 
NCMSRRMIPPM 
Project  Plans 


Phase  2 


Rqmts.  Specification 
(NISTIR  5707) 


MR  EXPRESS  Model 
MR  EXPRESS-G  Model 


MR  Data  Test  Environment 
Prototype  Implementations 


Industry  Review  of  Rqmts.  Spec. 
Electronic  Tooling  Catalog  — 
User  Group  Meeting 

Active: 

ISO  TC29/WG34 

ANSl/CCPA  B212  Advisory  Group 
Csmf£Ki?d; 

ISO  TC39 

ISO  TCI84/SC4/WG8 
ANSUASMEB5 


ANSI/ASMEB94 


Phase  6 


Events:  Japan-USA  Symposium  RRM  IPPM  Project  RRM  Process  Planning  Project 

Partners:  TEAM  CIM  GmbH  PDES,  Inc.  Scania/Sandvik  Coromant  lAMS  RRM  Steering  Committee 

Mechanisms:  RRM  Book  Chapter  Prototype  MR  Database  Journal  Article  RRM  Web  Page 

FIGURE  5:  MANUFACTURING  RESOURCE  IMES  EXAMPLE 
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Chapter  3:  SIMA  Approval  Process  for  Completion  of  IMES  Development  Phases 


3.1  Chapter  Overview 

This  chapter  defines  the  characteristics  of  IMES  results  that  are  expected  to  be  produced  within  a 
SIMA  project  and  the  approval  process  for  completing  each  phase  of  the  IMES  development 
project.  This  section  will  outline  the  overall  characteristics  and  the  requirements  for  completing 
each  of  the  various  phases  which  include: 

• Identifying  industry  need; 

• Analyzing  requirements; 

• Designing/developing; 

• Validating; 

• Building  consensus; 

• Transferring  technology;  and 

• Initiating  standardization. 

3.2  Content  and  Characteristics  of  IMES  Deliverables  . 

Completing  each  phase  requires  completing  the  primary  IMES  deliverables  and  possibly  one  or 
more  supporting  deliverables  depending  on  the  nature  of  the  project.  The  elements  witlun  a 
document  wiU  vary  based  on  the  type  of  interface  defined. 

The  IMES  project  deliverables  shall  have  the  following  characteristics: 

• Appropriate  scope:  Document  a scope  that  is  weU-defined,  with  clear  bounds  and  purpose. 
State  the  context  of  each  deliverable  with  respect  to  the  previously  defined  scope  and 
scenario. 

• Required  reference  information;  Specify  references  to  any  other  interfaces,  specifications, 
and  definitions  that  are  required  to  interpret  the  IMES  deliverable  and  the  publication  date  of 
the  reference  in  an  introductory  section  of  the  IMES.  Avoid  replicating  existing  work  already 
accomplished. 

• Consistent  use  of  methods:  Where  sufficient,  use  well-defined  and  industry-accepted 
specification  methods.  AU  IMES  deliverables  shall  be  consistent  in  their  use  of  any 
information  and  process  modehng  method  employed  in  the  work.  Usage  guidelines  exist  for 
many  of  the  methods  which  are  candidates  for  selection  by  SIMA  projects. 

• Compatible  interfaces:  Reuse  existing  data  and  functional  models  wherever  possible  to 
provide  a mechanism  for  interoperable  apphcations.  Interim  deliverables  should  be  accessible 
to  facihtate  developing  compatible  interfaces  among  IMES  deliverables.  Deliverables  should 
have  a modular  design  based  on  functional  capability.  Common  requirements  among  IMESs 
should  be  satisfied  by  a common  interface. 

• Traceability:  Each  IMES  development  phase  shall  contain  elements  which  are  traceable  to 
input  from  a prior  phase.  For  example,  a information  model  from  the  Development  Phase  3 
shall  contain  elements  which  are  traceable  to  the  requirements  identified  in  Phase  2. 
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33  Approval  Process  for  Completing  a Phase 

Since  there  is  more  than  one  allowable  entry  point,  due  to  the  opportunity  to  leverage  existing 
work,  this  process  describes  only  what  is  necessary  to  say  that  a given  phase  is  complete.  Phases 
and  deliverables  from  each  phase  are  described  in  section  2.2  of  this  document. 

Phase  1 - Identify/Define  Industry  Need 

In  this  phase  an  IMES  planning  proposal  is  submitted  to  the  sponsoring  laboratory  management 
for  review  and  approval.  The  mechanism  used  for  laboratory  approval  is  review^approved  by 
the  SIMA  Program  Office.  This  should  be  a brief  document  that  identifies  the  industry  need, 
describes  the  context  of  the  document  in  the  overall  SIMA  architecture  [BAR96],  and  documents 
the  envisioned  benefits  of  the  work.  The  kind  of  IMES  deliverable  to  be  produced  should  also 
be  identified.  It  should  describe  the  industrial  context  which  should  include  identifying  the 
industry  sector  that  is  the  target  audience,  a manufacturing  scenario  in  which  the  IMES  would 
operate,  the  types  of  products  and  applications  which  the  IMES  is  applicable  to,  the  types  of 
companies  needed  to  participate,  and  any  beneficial  strategic  alliances  with  consortia  or 
associations. 

Completing  this  phase  requires: 

• Approval  of  the  IMES  project  proposal,  including  preliminary  statement  on  the  scope  and 
relationships  to  other  projects,  by  the  SIMA  Program  Office; 

• Approval  by  the  SIMA  Program  Office  of  the  proposed  mechanism  to  be  used  for  the 
external  review  by  mdustry;  and 

• Review  and  approval  by  the  sponsoring  laboratory  management. 

Phase  2 - Analyze  Requirements 

Completing  this  phase  requires  that  the  deliverables  have  a clear  and  consistent  statement  of 
requirements  that  are  associated  with  explicit  functions  within  the  IMES  scope.  The 
requirements  specification  should  document  the  results  of  the  analysis  and  should  include  an 
analysis  of  representative  implementations  or  solutions,  relevant  standards,  and  priorities. 
Alliances  with  consortia  or  technical/trade  associations  can  be  an  efficient  means  of  collecting 
and  identifying  industry  requirements  and  priorities.  The  method  for  documenting  requirements 
and  setting  priorities  should  be  identified.  Identifying  the  applicability  to  the  previously  defined 
manufacturing  scenario  should  be  stated,  when  appropriate,  to  provide  a context  for  reviewers. 

Completing  this  phase  requires: 

• Agreement  by  the  project  team,  related  project  leaders  and  industry  collaborators,  as 
documented  by  minutes  or  other  informal  means,  that  the  requirements  specification  is  ready 
for  broader  review; 

• Identification  and  SIMA  Program  Office  approval  of  the  mechanism  to  be  used  for  obtaining 
broader  industry  review  of  the  IMES; 

• Evidence  of  efforts  to  obtain  industry  feedback  are  documented.  The  results,  means  and 
breadth  of  activities  should  be  stated  which  include:  list  of  issues,  list  of  active  industry 
reviewers,  and  list  of  workshops  conducted  with  industry  representatives;  and 

• Agreement  by  the  project  leader  and  SIMA  Program  Office  that  the  selected  requirements 
method  has  b^n  consistently  applied. 
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Phase  3 - Design/Develop 

Since  the  solution  may  consist  of  multiple  deliverable  types,  including  information  model(s), 
interface  protocol(s),  and/or  process  model(s),  as  required  by  the  project,  each  type  of  deliverable 
may  require  different  assessment  criteria.  The  project  should  document  how  the  requirements  are 
satisfied  by  the  specification  (the  primary  deliverable  of  this  phase).  Specific  aspects  of  any 
interface  specifications  which  potentially  interoperate  or  otherwise  impact  other  current  or 
planned  SIMA  projects  should  be  reviewed  by  the  SIMA  Program  Office.  Some  industry 
involvement  at  this  phase  is  expected.  There  may  be  direct  collaboration,  but  there  must  be 
evidence  of  one  or  more  industiy  reviews.  The  project  leader  is  responsible  for  identifying  which 
aspects  the  SIMA  Program  Office  and  other  SIMA  project  leaders  should  review.  The  SIMA 
Program  Office  is  assigned  the  responsibility  to  review  any  deliverables  and  determine  if  they  are 
consistent  with  the  stated  scope  and  requirements,  then  verify  that  the  specifications  are 
consistent  with  the  dehverables  in  the  project  plan. 

Completing  this  phase  requires: 

• A statement  of  collaborator  commitment  and  level  of  participation  is  provided; 

• An  industry  reviewer  judges  the  document  to  be  adequate  for  the  approved  scope; 

• A list  of  reviews  and  associated  industry  reviewers  is  provided  to  the  SIMA  Program  Office; 

• The  specification  fits  into,  and  is  consistent  with,  the  SIMA  architecture; 

• The  specification  is  consistent  with  the  approved  scope  and  demonstrates  traceability  to 
requirements; 

• The  SIMA  technical  reviewer  agrees  that  the  document  consistently  uses  selected  methods; 
and 

• a WERB-approveddraftIMES. 

Phase  4 - Validate 

A walk-through  with  domain  experts  on  how  the  specification  would  be  applied  to  the  usage 
scenario  is  a typical  initial  validation  activity.  The  example  input  and  output  data  identified 
during  requirements  definition  and  development  phases  should  be  used  for  building  test  cases. 
These  test  cases  should  capture  typical  operations  which  access  manufacturing  data  to  more 
concretely  validate  the  data  or  process  models.  Test  cases  should  be  defined  which  document 
coverage  of  the  functional  requirements  and  representation  specifications.  Any  guidance  on  the 
approach  to  be  used  should  be  referenced  and  followed.  It  is  not  generally  feasible  to  validate  aU 
aspects  of  a specification  so  it  is  important  to  set  priorities  and  document  which  aspects  were 
validated.  An  actual  system  prototype  with  more  than  one  vendor  or  a reference  implementation 
should  also  be  undertaken  to  provide  more  persuasive  results  where  appropriate.  The  list  of 
products  reviewed  or  used  and  vendor  representatives  participating  in  the  validation  should  be 
included  in  the  documentation. 

Completing  this  phase  requires: 

• A test  report  which  describes  the  validation  activities,  approach,  environment,  usage 
scenarios,  and  test  results,  including  a statement  of  what  was  covered  by  validation  (100%  is 
not  practical)  and  the  rationale  for  what  was  included  or  excluded  in  the  validation; 

• Test  cases  are  identified  and  documented  for  the  industry  scenario  defined  in  Phase  1;  test 
cases  should  pass  any  quality  checks  appropriate  for  the  interface  specification;  and 

• Documentation  indicating  that  industry  reviewers  judge  validation  coverage  to  be  adequate. 
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Phase  5 - Build  Consensus 


Completing  this  phase  requires  broad  review  by  members  of  the  target  industry  and  vendor 
community.  The  goals  are  acceptance  by  an  identified  user  community  and  affirmative  results 
from  the  call  for  participation  based  on  tbe  circulation  of  the  IMES  specification.  The  identified 
user  community  could  be  an  informal  or  accredited  standards  development  organization,  a 
consortium,  trade  association  or  any  alliance  of  companies  that  forms  to  meet  a common 
objective.  The  objective  of  this  Phase  is  to  gain  agreement  to  pilot  and  ultimately  use  the  IMES 
as  modified  by  a consensus  process,  and  to  obtain  buy-in  from  the  vendor  community  to  build 
products  to  the  specification. 

Completing  this  phase  requires: 

• Identification  of  the  method  used  to  obtain  consensus  by  the  sponsoring  organization; 

• Evidence  that  consensus  was  achieved  to  use  the  IMES  specification  as  the  strawman  for 
standardization  as  defined  by  the  consortium  or  accredited  standards  organization; 

• Commitment  from  a user  community  to  promote  use  of  the  specification;  and 

• Pilot  initiation  and  vendor  conunitment  to  product  development. 

Phase  6 - Transfer  Technology 

The  ultimate  proof  of  technology  transfer  is  evidence  that  commercial  implementations  of  the 
specification  are  being  used  in  production  applications.  Outputs  from  this  phase  can  include: 
system  demonstrations,  conference  presentations,  journal  articles,  releases  of  reference  software 
implementations,  or  WWW  project  description  pages.  The  project  leader  in  conjunction  with  the 
approval  of  SIMA  Program  Office  needs  to  determine  how  much  of  the  specification  is  suitable 
for  formal  standardization  and  anticipate  how  much  of  the  standards  process  will  require  active 
participation  by  the  project.  The  factors  involved  in  determining  this  participation  should  be 
documented  in  a final  report. 

Completing  this  phase  requires: 

• Final  report  judged  adequate  by  SIMA  Program  Office;  and 

• System  demonstration. 

Phase  7 - Initiate  Standardization 

This  phase  will  overlap  with  consensus  building  when  a viable  standards  activity  exists  which 
covers  the  scope  of  the  IMES.  If  such  an  activity  does  not  exist,  this  phase  will  include: 
identifying  a target  standards  development  organization,  the  proposal  of  a new  work  item  to  a 
standards  activity,  the  acceptance  of  this  new  work  item  by  an  informal  or  accredited  standards 
body  and  affirmative  results  from  the  call  for  participation,  and  the  circulation  of  the  IMES  as  the 
strawman  for  standardisation.  The  standards  development  procedures  become  the  principal 
approval  process.  The  rules  on  the  release  and  progression  of  the  proposed  draft  standard  will  be 
followed.  The  standards  process  places  additional  documentation  requirements  on  the 
development  team,  such  as  circulating  issues  and  resolutions.  The  project  leader  needs  to  track 
progress,  assess  the  participation  in  the  standards  project,  and  determine  when  active 
participation  in  the  standards  process  can  be  terminated. 
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Completing  this  phase  requires: 

• Successful  balloting  of  a new  work  item  proposal,  and  identifying  the  requirements  for 
participation; 

• A plan  specifying  necessary  requirements  to  complete  the  standardization  of  the  IMES 
through  a standards  development  organization. 

The  following  Table  2 provides  a summary  of  the  phase  completion  requirements  and  the 
responsible  authority  for  ensuring  each  aspect  of  completion  has  been  met. 


PHASE  COMPLETION  REQUIREMENTS 

PHASE 

PHASE  COMPLETION  REQUIREMENTS 

REVIEWER 

1 

• 

Approval  of  the  IMES  project  proposal,  including  preliminary 
statement  on  the  scope  and  relationships  to  other  projects; 

SIMA  Program  Office 

• 

Approval  of  the  mechanism  used  for  external  review. 

SIMA  Program  Office 

• 

Review  and  approval  by  the  sponsoring  laboratory 
management 

Laboratory  Management 

2 

• 

The  requirements  specification  is  ready  for  broader  review,  as 
documented  by  minutes  or  other  informal  means; 

Agreement  by  the  Project 
Team,  related  project 
leaders  and  industry 
collaborators 

• 

Evidence  of  efforts  to  obtain  industry  feedback  are 
documented.  The  results,  means  and  breadth  of  activities 
should  be  stated  which  include:  list  of  issues,  list  of  active 
industry  reviewers,  and  list  of  workshops  conducted  with 
industry  representatives; 

SIMA  Program  Office 
assesses  alliances  with 
industry  consortia  or  trade 
associations 

• 

The  selected  requirements  method  has  been  consistently 
applied  by  project  leader. 

Agreement  by  project 
leader  and  SIMA  Program 
Office 

• 

Identification  and  approval  of  the  mechanism  to  be  used  for 
obtaining  broader  industry  review  of  IMES. 

SIMA  Program  Office 

3 

• 

A statement  of  collaborator  commitment  and  level  of 
participation  is  provided; 

SIMA  Program  Office 

• 

Document  is  judged  to  be  adequate  for  the  approved  scope; 

Industry  reviewer 

• 

A list  of  reviews  and  industry  reviewers  is  provided  to  the 

SIMA  Program  Office; 

SIMA  Program  Office 

• 

The  specification  fits  into  and  is  consistent  with  the  SIMA 
architecture; 

SIMA  Program  Office 

• 

The  specification  is  consistent  with  approved  scope  and  it 
demonstrates  traceability  to  requirements; 

SIMA  Program  Office 

• 

The  SIMA  Program  Office  agrees  that  the  document 
consistently  uses  selected  methods; 

SIMA  Program  Office 

• 

WERE  approved  draft  IMES. 

NIST  WERE  authorities 
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4 

• 

A test  report  which  describes  the  validation  activities, 
approach,  environment,  usage  scenarios,  and  test  results, 
including  a statement  of  what  was  covered  by  validation 
(100%  is  not  practical)  and  the  rational  for  what  was  included 
or  excluded  in  the  validation; 

SIMA  Program  Office 

• 

Test  cases  are  identified  and  documented  for  the  industry 
scenario  defined  in  Phase  1;  test  cases  should  pass  any  quality 
checks  appropriate  for  the  interface  specification; 

SIMA  Program  Office 

• 

Judge  validation  coverage  to  be  adequate. 

Industry  reviewers 

5 

• 

Identification  of  the  method  used  to  obtain  consensus  by  the 
sponsoring  organization; 

SIMA  Program  Office 

• 

Evidence  that  consensus  was  achieved  to  use  the  IMES 

SIMA  Program  Office 

specification  as  the  strawman  for  standardization  as  defined 
by  the  consortia  or  accredited  standards  body; 

• 

Commitment  from  a user  community  to  promote  use  of  the 
specification; 

SIMA  Program  Office 

• 

Pilot  initiation  and  vendor  commitment  to  product 
development. 

SIMA  Program  Office 

6 

• 

Final  report  judged  adequate; 

SIMA  Program  Office 

• 

System  demonstration. 

SIMA  Program  Office 

7 

• 

Successful  ballot  of  a new  work  item  proposal,  including 

Standards  Development 

requirements  for  participation; 

Organization 

• 

Plan  to  support  completion  of  the  standard. 

Standards  Development 
Organization 

TABLE  2:  PHASE  COMPLETION  REQUIREMENTS 
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Chapter  4: 


Conclusion  and  Document  Status 


In  order  to  determine  the  success  of  the  IMES  concept  and  of  published  IMESs,  the  SIMA 
Program  Office  will  conduct  an  annual  assessment.  Basic  metrics  will  be  applied  to  each  IMES 
for  three  (3)  years  after  its  publication.  Metrics  for  assessment  may  include: 

• is  the  IMES  actively  progressing  through  a standards  development  organization? 

• are  implementations  of  the  IMES  being  built  by  commercial  enterprise  for  production  use? 

• are  users  applying  IMES  implementations  to  meet  their  requirements? 

• after  three  (3)  years  of  the  IMES's  publication,  has  it  been  deployed  in  some  fashion  by 
industry? 

This  document  has  attempted  to  capture  initial  thoughts  regarding  the  definition  of  an  IMES,  the 
development  process  for  creating  an  IMES,  and  approval  procedures  for  IMES  development 
projects.  The  procedures  described  in  this  document  are  considered  initial  concepts  and  will 
change  with  time  as  the  SIMA  project  leaders  gain  further  experience  with  IMES  development. 
As  EMES  development  projects  are  initiated  and  proceed  through  the  various  development 
phases,  it  is  expected  that  both  modifications  and  additions  to  this  document  will  be  identified. 

As  such,  this  concept  document  should  be  considered  a living  document.  Readers  should  feel  free 
to  provide  written  comments  to  the  following  for  consideration  in  future  updates  to  this 
information: 


SIMA  Program  Manager 
Jim  Fowler 

jefowler@cme.nist.gov 

or 

IMES  Document  Champion 
Sharon  Kemmerer 
kemmerer@cme.nist.gov 
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Appendix  B:  Glossary  of  Acronyms  and  Terms 


Acronyms 

ANSI- 

American  National  Standards  Institute 

AP- 

Application  Protocol 

API- 

Application  Programming  Interface 

ARM- 

Application  Reference  Model 

ASN.l  - 

Asynchronous  Syntax  Notation 

CAD- 

Computer-Aided  Design 

CD- 

Committee  Draft 

CORBA- 

Common  Object  Request  Broker  Architecture 

CRADA- 

Cooperative  Research  and  Development  Agreement 

DIS- 

Draft  International  Standard 

HPCC- 

High  Performance  Computing  and  Communications 

IDL- 

Interface  Description  Language 

lEC- 

International  Electrotechnical  Commission 

HTA- 

Information  Infrastructure  Technology  Applications 

IMES  - 

Initial  Manufacturing  Exchange  Specification 

ISA- 

Instrument  Society  of  America 

ISO- 

International  Organization  for  Standardization 

MADE- 

Manufacturing  Automation  and  Design  Engineering 

MOU- 

Memorandum  of  Understanding 

MSI  - 

Manufacturing  Systems  Integration 

MSID- 

Manufacturing  Systems  Integration  Division 

Nn- 

National  Information  Infrastructure 

Ninp- 

National  Industrial  Information  Infrastructure  Protocols 
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NIST- 

OMG- 

ORB- 

PCA- 

PDM- 

RADEO- 

RRM- 

SDAI- 

SDO- 

SIMA- 

SOLIS  - 

STEP- 


TEAM- 


WWW- 

Tenns 


National  Institute  of  Standards  and  Technology 

Object  Management  Group 

Object  Request  Broker 

Program  Component  Areas 

Product  Data  Manager 

Rapid  Design  Exploration  and  Optimization 

Rapid  Response  Manufacturing 

Standard  Data  Access  Interface  (ISO  DIS  10303-22) 

Standards  Development  Organization 

Systems  Integration  for  Manufacturing  Applications 

SC4  On-Line  Information  Service 

Standard  for  the  Exchange  of  Product  model  data  (informal  name  of  ISO  10303, 
Industrial  automation  systems  and  integration  - Product  data  representation  and 
exchange  ) 

Technology  for  Enabling  Agile  Manufacturing 
World  Wide  Web 


Application  Programming  Interface  - a set  of  procedures,  usually  written  in  some  standard 
programming  language,  callable  from  an  external  user-generated  program.  Such  procedures  may 
provide  access  to  some  of  the  functions  of  the  application  system,  or  provide  access  to  the  data  it 
maintains,  or  both.  [BAR95] 

Application  Protocol  - a part  of  this  International  Standard  [ISO  10303]  that  specifies  an 
application  interpreted  model  satisfying  the  scope  and  information  requirements  for  a specific 
application.  [10303-1] 

Class  Library  — a kind  of  API  specification  in  which  the  interface  is  specified  in  terms  of 
information  objects  and  the  operations  on  them.  Class  libraries  are  language-specific  and  the 
term  often  implies  a C-H-  implementation. 

Common  Object  Request  Broker  Architecture  — the  canonical  distributed  systems  architecture 
proposed  by  OMG. 
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High  Performance  Computing  and  Communications  - A federal  government  initiative  whose 
go^  is  to  accelerate  the  development  of  future  generations  of  high  performance  computers  and 
networks  and  the  use  of  these  resources  in  the  Federal  government  and  throughout  the  American 
economy.  The  HPCC  program  fully  supports  and  is  closely  coordinated  with  the  effort  to 
accelerate  the  development  and  deployment  of  the  Nation^  Information  Infrastructure  (NH).  The 
Program  and  its  participating  agencies  help  provide  the  basic  research  and  technological 
development  to  support  Nil  implementations. 

Interface  Description  Language  - a language  for  specifying  the  API  to  an  application  software 
package.  DDLs  are  designed  to  avoid  the  idiosyncrasies  of  particular  programming  languages  and 
tools  are  then  developed  to  provide  the  mapping  of  an  API  phrased  in  DDL  into  subroutines 
compatible  with  a user's  target  programming  language.  The  subroutines  employ  some 
service/protocol  associated  with  the  DDL  to  access  the  software  package.  Two  DDLs  are  in 
common  use:  the  CORBA  DDL,  whose  tools  use  an  Object  Request  Broker,  and  the  Distributed 
Communications  Environment  (DCE)  DDL,  whose  tools  use  (unix)  Remote  Procedure  Calls 
(RPC). 

Information  Model  - a formal  identification  of  the  objects  in  an  interchange,  their 
interrelationships,  and  the  information  units  which  describe  those  objects.  It  may  or  may  not 
include  identification  of  the  operations  on  those  objects. 

Initial  Manufacturing  Exchange  Specification  - A clear  written  description  of  WHAT 
information  the  interface  or  repository  MUST  convey,  and  possibly  HOW  it  is  conveyed. 

Interface  Protocol  - a formal  description  of  the  messages  exchanged  between  two 
communicating  entities  and  the  rules  for  the  exchange  of  those  messages. 

Interoperability  - the  successful  exchange  and  use  of  information  between  two  or  more 
dissimilar  systems  [KEM92]. 

Process  Model  - a formal  description  of  the  behavior  of  a system,  including  the  activities  it 
performs  and  the  required  states  or  events  which  will  cause  it  to  perform  them.  (A  programming 
language  is  a process-modeling  language,  but  at  a very  fine  degree  of  detail.) 

Product  Data  Manager  - an  information  system  whose  function  is  to  maintain  collections  of 
data  and  to  provide  them  to  other  information  systems  (such  as  application  packages)  on  request. 
The  rules  for  modification  of  the  information  in  the  repository  (who/when)  define  behavior^ 
characteristics  that  typify  certain  subtypes  of  repository.  We  distinguish  between  reference 
repositories,  which  most  customers  cannot  modify,  and  interface  repositories,  which  are  routinely 
read  and  modified  by  all  participants  to  the  interface. 

Protocol  - the  rules  for  communicating:  see  Interface  Protocol  and  Application  Protocol  terms. 
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Appendix  C:  Related  Documents 


Methods  Documents 

Several  methods  documents  for  preparing  STEP  parts  have  been  approved  as  SC4  Standing 
Documents  for  use  within  the  ISO  TC  184/SC4  community.  The  current  titles  are  listed  here, 
and  they  are  available  on-line  from  SC4  On-Line  Information  Service  (SOLIS)  under  the 
common  directory  path:  SC4/how  to/methods/.  The  current  SC4  N#s  are  also  designated; 
however,  SIMA  project  managers  are  encouraged  to  ensure  the  most  recent  version  is  applied 
when  undertaking  IMES  development.  Although  these  methods  documents  are  currently  specific 
to  STEP,  SIMA  project  managers  may  also  find  them  useful  for  other  IMES  development  as 
well. 

• SC4  N 432  Supplementary  directives  for  the  drafting  and  presentation  of  ISO  10303 

• SC4  N 433  Guidelines  for  the  development  and  approval  of  STEP  application  protocols 

• SC4  N 434  Guidelines  for  the  development  of  abstract  test  suites 

• SC4  N 435  Guidelines  for  AIM  development 

• SC4  N 436  Guidelines  for  the  development  of  mapping  tables 

• SC4  N 437  Guidelines  for  AIC  development 

Standards  Development  Organization  Directives  and  Guidelines 

ISO  Directives  and  other  Publications. 

The  following  are  the  most  current  versions  of  Parts  1 through  3 of  the  ISO  Directives: 

ISO  Directives  Part  1,  Procedures  for  the  technical  work  , June  1995. 

ISO  Directives  Part  2,  Methodology  for  the  development  of  International  Standards, 

1989. 

ISO  Directives  Part  3,  Drafting  and  presentation  of  International  Standards,  1989. 

These  directives,  other  ISO  style  guides  and  publications,  and  published  SC4  international 
standards  are  available  through  ISO  Central  Secretariat.  Purchasing  information  can  be  found  on 
the  "Welcome  to  ISO  Online"  world  wide  web  home  page: 

http://www.iso.ch/welcome.html 
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Appendix  D:  Examples  for  Deliverables 


This  appendix  consists  of  references  to  existing  documents  or  sources  of  information  that 
illustrate  examples  of  specific  types  of  IMES  deliverables.  These  examples  are  pouped  by  IMES 
phases  and  the  specific  ^e  of  aeliverable  (primary  and  secondary)  is  identified  for  each  example 
as  appropriate  to  that  IMES  phase. 

Please  note:  The  editor  of  this  document  recognizes  that  this  appendix  does  not  include  examples 
for  all  deliverables.  It  is  expected  that  future  editions  of  this  document  will  be  able  to  reflect 
developmental  growth  of  the  IMES  concepts  and  further  clarify  through  future  examples  listed 
here. 

Phase  1 - Identify/Define  Industry  Need 

Type:  Problem  Statement 

• Example:  Jurrens,  Kevin  K.,  Mary  Elizabeth  A.  Algeo,  and  Jim  Fowler,  "Beyond  Product 
Design  Data:  Data  Standards  for  Manufacturing  Resources,"  to  be  published  as  Chapter  5 in 
Rapid  Response  Manufacturing:  Contemporary  Methodologies.  Tools,  and  Techniques,  Dr. 

Jian  Dong  (editor).  Chapman  and  Hall,  1996. 

• Example:  Rosenfeld,  David  A.,  Shantanu  Dhar,  Procedure  for  Product  Data  Exchange  Using 
STEP  Developed  in  the  AutoSTEP  Pilot.  NISTIR  5833,  National  Institute  of  Standards  and 
Technology,  April  1996. 

Type:  Manufacturing  Scenario 

• Example:  Jurrens,  Kevin  K.,  Mary  Elizabeth  A.  Algeo,  and  Jim  Fowler,  "Beyond  Product 
Design  Data:  Data  Standards  for  Manufacturing  Resources,"  to  be  published  as  Chapter  5 in 
Rapid  Response  Manufacturing:  Contemporary  Methodologies.  Tools,  and  Techniques,  Dr. 

Jian  Dong  (editor).  Chapman  and  Hall,  1996. 

Type:  Project  Plan 

• Example:  Jurrens,  Kevin  K.,  and  Mark  E.  Luce.  Project  Plan  for  the  Rapid  Response 
Manufacturing  (RRM)  Intramural  Project.  NISTIR  5174,  National  Institute  of  Standards  and 
Technology,  February  1993. 

Type:  Industry  Needs  Surveys 

• Example:  Barkmeyer,  Edward  J.,  Theodore  H.  Hopp,  Michael  J.  Pratt,  and  Gaylen  R. 
Rinaudot,  editors.  Background  Study  - Requisite  Elements.  Rationale,  and  Technology 
Overview  for  the  Systems  Integration  for  Manufacturing  Applications  (SIMA)  Program. 

NISTIR  5662,  National  Institute  of  Standards  and  Technology,  September  1995. 

Type:  Workshop  Proceedings 

• Example:  Ray,  Steven  R.,  editor.  Proceedings  of  the  1993  Industrial  Process  Planning 
Workshop.  June  17-18, 1993,  Gaithersburg,  MD,  NISTIR  5284,  National  Institute  of 
Standards  and  Technology,  October  1993. 

Type:  CRADAs 

In  general,  CRADA  content  is  proprietary  in  nature.  Because  of  this,  it  is  not  appropriate  to  cite 
particular  CRADAs  in  exemplar  form.  The  technical  representatives  from  NIST's  Technology 
Services  Office  identified  for  each  NIST  operating  unit.  These  representatives  can  assist  you  for 
your  particular  needs. 
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Type:  MOUs 

• [Industrial]  Example:  Industrial  Memorandum  of  Common  Understanding  on  the  Use  of 
STEP  (ISO  10303).  The  aerospace  signature  parties  represented  on  this  MOU  are  Rolls- 
Royce,  Pratt  & Whitney,  General  Electric,  Boeing  Commercial  Airplane  Group,  and  Snecma. 
The  purpose  of  the  MOU  is  to  define  a common  understanding  with  respect  to  the  increasing 
importance,  development,  and  usage  of  the  product  data  standard  STEP  (ISO  10303).  Copies 
of  this  industrial  MOU  can  be  obtained  through  NIST’s  ISO  TC  184/SC4  Secretariat  Office, 
Building  220,  Room  A240. 

Type:  Industry  Support  Letters 

• Example:  STEP  Automotive  Special  Interest  Group  (SASIG)  Letter  of  December  5,  1995. 
SASIG  is  comprised  of  four  automotive  associations  (France,  Germany,  Japan,  and  USA),  to 
further  enhance  cooperation  with  CAD/CAM  product  developers  to  support  development  and 
implementation  of  specific  ISO  10303  apphcation  protocols.  Copies  of  this  industry  support 
letter  can  be  obtained  through  NIST's  ISO  TC  184/SC4  Secretariat  Office,  Building  220, 
Room  A240. 

Phase  2 - Analyze  Requirements 

Type:  Requirements  Specification  for  a Proposed  Solution 

• Example:  Jurrens,  Kevin  K.,  James  E.  Fowler,  and  Mary  Elizabeth  A.  Algeo,  Modeling  of 
Manufacturing  Resource  Information.  Requirements  Specification.  NISTIR  5707,  Rapid 
Response  Manufacturing  (RRM)  Intramural  Project,  National  Institute  of  Standards  and 
Technology,  July  1995. 

• Example:  Kline,  Steven  W.,  Mark  E.  Palmer,  Group  1 for  the  Plant  Spatial  Configuration 
STEP  AP.  NISTIR  5675,  National  Institute  of  Standards  and  Technology,  June  1995. 

• Example:  Kline,  Steven  W.,  Mark  E.,  Palmer,  et  al.  Process  Engineering  Data:  Process 
Design  and  Process  Specifications  of  Major  Equipment  Application  Protocol  Group  L 

NISTIR  5909,  National  Institute  of  Standards  and  Technology,  October  1996. 

Type:  Industry  Data 

• Example:  Moncarz,  Howard  T.,  Program  Requirements  to  Advance  the  Technology  of 
Custom  Footwear  Manufacturing,  NISTIR  5521,  National  Institute  of  Standards  and 
Technology,  October  1994. 

Type:  Literature  Review 

• Example: 

Type:  Standards  Review 

• Example:  Pawlak,  Craig  G.,  A Survey  of  Standards  for  the  U.S.  Fiber/Textile/Apparel 
Industry.  NISTIR  5823,  National  Institute  of  Standards  and  Technology,  April  1996. 

Type:  Application  Software  Review 

• Example: 

Type:  State-of-the-Art  Assessments 

• Example:  Jurrens,  Kevin  K,  An  Assessment  of  the  State-of-the-Art  in  Rapid  Prototyping 
Systems  for  Mechanical  Parts.  NISTIR  5335,  Rapid  Response  Manufacturing  (RRM) 
Intramural  Project,  National  Institute  of  Standards  and  Technology,  December  1993. 

• Example:  Ressler,  Sandy,  Applying  Virtual  Environments  to  Manufacturing.  NISTIR  5343, 
National  Institute  of  Standards  and  Technology,  January  1994. 
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• Example:  Fowler,  James  E.,  Variant  Design  for  Mechanical  Artifacts-A  State  of  the  Art 
Survey.  NISTIR  5356,  National  Institute  of  Standards  and  Technology,  Februaiy  1994. 

• Example:  Algeo,  Mary  Elizabeth  A.,  A State-of-the-Art  Survey  of  Methodologies  for 
Representing  Manufacturing  Process  Capabilities.  NISTIR  5391,  National  Institute  of 
Standards  and  Technology,  March  1994. 

• Example:  Moncarz,  Howard  T.,  Visualization  Applications  for  Manufacturing  - A State-of- 
the-Art  Survey.  Final  Report.  NISTIR  5427,  National  Institute  of  Standards  and  Technology, 
May  1994. 

• Example:  Algeo,  Mary  Elizabeth  A.,  Shaw  Feng,  and  Steve  Ray,  A State-of-the-Art  Survey 
on  product  Design  and  Process  Planning  Integration  Mechanisms.  NISTIR  5548,  National 
Institute  of  Standards  and  Technology,  December  1994. 

Type:  Workshop  Proceedings 

• Example:  Ray,  Steven  R.,  editor.  Proceedings  of  the  1993  Industrial  Process  Planning 
Workshop.  June  17-18,  1993,  Gaithersburg,  MD,  NISTIR  5284,  National  Institute  of 
Standards  and  Technology,  October  1993. 

Type:  Identification  of  Potential/Appropriate  Standards  Bodies 

• Example:  Review  of  the  ISO  homepage  for  existing  level  of  effort  and  functional  coverage: 
http://www.iso.ch/welcome.html 

• Example:  Review  of  the  ANSI  homepage  for  existing  level  of  effort  and  functional  coverage: 
http://www.ansi.org 

Phase  3 - Design/Develop 

Type:  Initial  Strawman  IMES 

• Example:  Sara  Wallace,  M.  K.  Senehi,  Edward  Barkmeyer,  Steven  Ray  and  Evan  Wallace: 
Manufacturing  Systems  Integration  Control  Entity  Interface  Specification.  NISTIR  5272, 
National  Institute  of  Standards  and  Technology,  Gaithersburg,  MD,  1993. 

• Example:  Lee,  Tina  Y.,  Howard  T.  Moncarz,  A Prototype  Application  Protocol  for  Readv- 
To-Wear  Pattern  Making.  NISTIR  5115,  National  Institute  of  Standards  and  Technology, 
January  1993. 

• Example:  Kline,  Steven  W.,  Mark  E.  Palmer,  Plant  Spatial  Configuration  Application 
Protocol.  Version  1.0  - Volumes  1 & 2.  NISTIR  5812,  National  Institute  of  Standards  and 
Technology,  December  1995. 

Type:  Information  Model(s) 

• Example:  EXPRESS  model  of  machine  tool,  cutting  tool,  and  tooling  components.  Rapid 
Response  Manufacturing  (RRM)  Intramural  Project,  November  1995. 

Type:  Interface  Protocol(s) 

• Example: 

Type:  Process  Model(s) 

• Example:  Feng,  Shaw  C.,  A Machining  Process  Planning  Activity  Model  for  Systems 
Integration.  NISTIR  5808,  National  Institute  of  Standards  and  Technology,  March  1996. 
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Phase  4 - Validate 


Type:  Test  Results 

• Example;  Smith,  Mike,  Swee  Leong,  Computer-Aided  Manufacturing  Engineering  Forum. 
Second  Technical  Meeting  Proceedings,  Hilton  Hotel.  Gaithersburg.  MD.  August  22-23. 

1995,  NISTIR  5846,  National  Institute  of  Standards  and  Technology,  May  1996. 

Type:  Prototype  Implementation 

• Example:  STEP  Tools,  Inc:  http://www.steptools.com/products.html 

• Example:  PDES,  Inc.  Pilot/Demonstrations:  http://www.scra.org/pdesinc/deploy.html 

Type:  Test  Environment 

• Example:  NIST's  STEP  Application  Protocol  Information  Base  Web  Gateway  to  identify 
existing  ISO  10303  application  protocol  requirements:  http://elib.cme.nist.gov/apde/ 

• Example:  Rosenfeld,  David  A.,  Reference  Manual  for  the  Algorithm  Testing  System  Version 
2.0,  MSTIR  5722,  National  Institute  of  Standards  and  Technology,  October  1995. 

• Example:  MitcheU,  Mary,  Initial  NIST  Testing  Policy  for  STEP  Beta  Testing  Program  for 
AP203  Implementations,  NISTIR  5535,  National  Institute  of  Standards  and  Technology,  3 
November  1994. 

Type:  Test  Suites 

• Example:  ISO  10303  Conformance  Testing  Service  on-line  tools  through  WWW: 
http://www.iti,org/cec/steptest/steptest.htm 

Phase  5 - Build  Consensus 

Type:  Reviewed/Harmonized  EMES 

• Example: 

Type:  Workshop  Proceedings 

• Example: 

Type:  Industry  Review 

• Example: 

Type:  Standards  Development  Organization  Review 

• Example:  ISO/DIS  10303-202  ballot  comments  found  on  SOLIS:  sc4/step/parts/part202/dis 

Type:  Industry  User  Group  Interest/Actions 

• Example: 

Phase  6 - Transfer  Technology 

Type:  IMES  Final  Report 

• Example: 

Type:  System  Demonstrations 

• Example: 
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Type:  Conference  Presentations 

• Example:  Fowler,  James  E.,  Algeo,  Mary  Elizabeth  A.,  and  Kevin  K.  Jurrens.  Computerized 
Representation  of  Manufacturing  Resources:  Statement  of  Need  and  a Proposed  Solution. 

Proceedings  of  the  Japan  - USA  Symposium  on  Rexible  Automation:  1996,  New  York: 
American  Society  of  Mechanical  Engineers,  1996,  Volume  1,  pp.  695-697. 

• Example:  Algeo,  Mary  Elizabeth  A.,  Fowler,  James  E.,  and  Kevin  K.  Jurrens.  Computerized 
Representation  of  Manufacturing  Resources:  Validation  and  Standardization  Efforts. 

Proceedings  of  the  Japan  - USA  Symposium  on  Flexible  Automation:  1996,  New  York: 
American  Society  of  Mechanical  Engineers,  1996,  Volume  1,  pp.  699-702. 

Type:  Journal  Articles 

• Example:  Jurrens,  Kevin  K.,  Mary  Elizabeth  A.  Algeo,  and  Jim  Fowler,  "Beyond  Product 
Design  Data:  Data  Standards  for  Manufacturing  Resources,"  published  as  Chapter  5 in  Rapid 
Response  Manufacturing:  Contemporary  Methodologies.  Tools,  and  Techniques.  Dr.  Jian 
Dong  (editor).  Chapman  and  Hall,  1996. 

• Example:  Fowler,  J.E.,  “Variant  Design  for  Mechanical  Artifacts:  A State-of-the-Ait 
Survey,”  Engineering  with  Computers.  (1996)  12:1-15,  Springer- Verlag  London  Limited. 

Type:  WWW  Homepages 

• Example:  ISO  10303  short  names  database:  http://www.cme.nist.gov/cgi-in/apde/sc4short.tcl 

• Example:  RRM  Intramural  Project  home  page:  http :/www. nist.gov/rrm 

Type:  Vendor  Implementations 

• Example:  PDES,  Inc.  STEP  translator  announcements: 
http://www.scra.org/pdesinc/vendor.html 

Type:  End-User  Implementations 

• Example:  Production  use  of  ISO  10303  announcements: 
http://www.scra.org/pdesinc/news.html 

Type:  Commercialization  Plan 

• Example: 

Type:  Toolkit  Software  Release 

• Example:  ISO  10303  conformance  testing  service: 
http://www.iti.org/cec/steptest/steptest.htm 

Phase  7 - Initiate  Standardization 

Type:  Standards  Development  Organization  New  Work  Item 

• Example:  New  Work  Item  for  ISO  10303-227  (application  protocol)  and  ISO  10303-327 
(abstract  test  suite),  “Plant  spatial  configuration.” 

• Example:  New  Work  Item  for  ISO  10303-231  (application  protocol)  and  ISO  10303-33 1 
(abstract  test  suite),  “Process  engineering  data:  Process  design  and  process  specification  of 
major  equipment.” 

Type:  Strawman  Proposal  Recognized  as  CD  Status 

• Example:  Committee  draft  for  ISO  10303-227,  “Application  protocol:  Plant  spatial 
configuration.” 
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Type:  Strawman  Proposal  for  Standardization 

• Example:  ISO/TC29AV634  N4a.  Part  Library  Data  for  Turning  Tools:  Contribution  to  ISO 
TC29AV634.  J.E.  Folwer,  K.K.  Jurrens,  and  M.E.  Algeo,  November  13,  1995. 

Type:  Standards  Development  Organization  New  Working  Group 

• Example:  ISO  TC29/WG34,  for  progressing  the  cutting  tool  aspects  of  the  manufacturing 
resource  data  IMES. 

Type:  Amendment  or  Technical  Corrigendum  to  Existing  Standard 

• Example: 

Type:  Implementors'  Agreement/Profile 

• Example: 

Type:  Project  Plan  and  Schedule  for  Developing  IMES  Through  Standards  Development 
Organization 

• Example: 
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APPENDIX  E:  Description,  Roies  and  Responsibilities  of  Those 
Involved  in  IMES  Process 


SIMA  Program  Manager: 

- responsible  for  implementing  the  IMES  concepts,  development  process,  and  approval 
procedures  within  the  SIMA  Program 

- builds  IMES  project  requirements  into  SIMA  Program  milestones  and  schedule 

- focal  point  for 

- information  regarding  various  IMES  development  efforts 

- questions  regarding  the  IMES  development  process  or  approval  procedures 

- IMES  presentations  and  marketing 

- ensures  SIMA  Project  Managers  are  responsive  to  the  requirements  of  each  IMES  phase 

- conducts  annual  assessment  of  published  IMESs  to  determine  whether  the  specification  has 
been  deployed  by  industry 

IMES  Document  Champion: 

- serves  as  editor  of  the  IMES  Concept  Document 

- works  closely  with  the  SIMA  Program  Manager  and  MSID  Leadership  Team  to: 

- develop  presentations  and  IMES  marketing  briefs 

- provide  IMES  presentations  as  necessary 

Project  Team: 

Members  working  coUaboratively  under  SIMA  funding  to  develop  an  IMES  to  meet  a particular 
industry  need. 

Project  Leader: 

Individual  heading  up  the  SIMA-funded  project  to  develop  an  IMES  to  meet  a particular  industry 
need. 

Industry  Collaborators: 

Representatives  committed  by  an  industry  consortium  or  trade  association  to  actively  work  with 
the  SIMA  project  to  develop  an  IMES. 

Industry  Reviewer: 

Someone  from  industry  with  a vested  interest  to  ensure  his/her  manufacturing  requirements  are 
met  by  the  IMES. 

SIMA  Program  Office: 

The  composite  of  staff  under  the  management  of  the  SIMA  Program  Manager. 

NIST  WERE  Authorities: 

NIST  laboratory  representatives  responsible  for  ensuring  WERE  procedures  are  followed  and 
quality  publications  are  produced. 

Standards  Development  Organization: 

National  or  international  organization  whose  primary  purpose  is  the  development  and 
deployment  of  standards  to  meet  industry  requirements. 


37 


1 fe't'  '^^'<- 

...JiiiililfflS, 

t-4>  ■ h :■*  i ^ 

'%I*‘ik';.vr-;':^i^i>' - "■' 


■'V' 


mK 


Mi 


iifi 


c-r'. 


im 


m 


m 


> -i,  ' * - r:*  V . 


«V75' 


ilf 


^ ^ V’"  '^,  V/.? 

I « '/  i'iX  Ll  ,:-  .,_- 


■ S-»- 


l^'- 


■ ^-■.'«  <"'T.'  y.'i'T  ■ 1'  ^'  i.x  v»v  » .*•  j • « *»f^  1 


kff. 


k-m 


. , 


tM'i 


mMm 


'©4 


«»/,■  ^ 


'^if  ‘ . I ■..'■^■.  ■ 


Kll- : "■  '■'■  '-=  >V'V.-  •: 


